Attributes and Examples of Clear Expectations

The best expectations are comprehensible, measurable, and actionable. Let's look at each of these attributes.

Comprehensible expectations#

Employee expectations are not the place to be hip to all the latest corporate jargon. Telling your employees they need to "synergize with the latest upward trends in disruptive technology paradigms" means what, exactly? Like any agile feedback loop, your employee needs to know what you're expecting of them, and the simpler the expectation can be phrased, the easier it will be for the employees to parse and understand. Remember, you're always there to answer any questions they have, and forcing yourself to write it out simply and clearly in turn forces you to think about what you expect your employees to be doing on a level that you hadn't considered before, either. "Explain it to me like I'm five years old" is a popular meme across social media, and while we generally don't expect to be managing teams of five-year-olds, a reasonable parallel to the meme might be, "Explain it to me like I'm fifteen."

Measurable expectations#

This isn't quite the same as metrics (which we'll discuss later in the course), but metrics certainly can qualify as measurable. The key here is to be able to determine how somebody is improving or not without requiring subjective assessment. "Writes good code," for example, is useful only insofar as we can all agree on what "good code" means—and most of us can't. (Try it sometime: Ask your peers what "good code" looks like, complete with examples, and you'll find that once you get past naming conventions, it gets muddy quickly.) "Spends 5% of work time providing input on others' work" is clear and measurable. We can then drill deeper into what that input looks like, and/or the quality of that input, but on the whole, any measurable expectation should be one that a disinterested third party can evaluate and get to roughly the same answer as you.

Actionable expectations#

The candidate needs to be able to act on the expectation. If the expectation depends on others' opinions of the employee or relies on an external survey score (such as users' opinions of the application or Glassdoor reviews of the company), it will simply create stress on the part of the employee. "Learn one new software development topic per year," on the other hand, is a directly actionable item.

It's important to make sure that the company provides the environment in which those actions are possible. In other words, if you have the learning example as one of your expectations of your employees, make sure that the company has some kind of learning/self-development/training support—you pay for online learning subscriptions, for example, or you send employees to training classes once a year, and so on—and there's time during the work day to get that learning/training in. Expecting employees to do this learning on their own time, at their own expense, without any corporate support, is going to discriminate against those employees who have after-hours obligations.

Are metrics alone enough? Note that there is a strong temptation among engineering managers to boil down expectations to metrics. However, trying to manage a team solely by watching metrics is much like trying to influence your immediate environment by watching—and manipulating—the thermometer. Are you feeling chilly? Hold the thermometer over the fire! Too warm? Surround it with ice! The thermometer will respond to the changes you put it through, but it won't make the room around you warmer or colder.

Examples of clear expectations#

Some examples of pretty reasonable expectations (each at very different levels of seniority) include these:

• "Displays a solid understanding of core CS fundamental concepts." We might have some disagreement on what "solid understanding" means precisely, or what topics are part of "core CS fundamentals," but on the whole, most disinterested third parties will be able to recognize somebody who fumbles a discussion of linked lists vs binary trees, or can't really explain big-O notation.

• "When given a task with unclear requirements {these engineers} know how to ask for clarification, ensuring that all assumptions are vetted before work starts to reduce the need for re-work." It's pretty clear, and it's reasonably measurable: how many should-have-been-expected-but-wasn't questions come up down the road, how many questions does the engineer ask up front, how many of those questions are relevant to the project and/or proposed implementation, and so on. And it's somewhat actionable. Growing somebody in this area will probably require some mentoring and/or some self-study if they don't meet the expectations, since it'll be hard to know what level of "vetting" is appropriate (as opposed too much or too little).

• "The {engineer} is viewed as the go-to expert in some significant area of the code base, and not just because they are the only person who has ever worked in that code base." If you've worked at a company that had one of these, you'd know exactly what's being described here. At one company I worked at, his name was Ron, and on our team of five he was the "designated bug guy"—his job, for the first six months he was on the team, was to go and fix bugs all over the system. By the end of that time, he had become the resident expert on just about every part of the application, and he quickly became that "go-to" guy for any questions anybody had about a part of the system they hadn't worked on before. Here, the expectation is measurable—do people go to that person, or not?—and clear. The actionability is a little less obvious, but it probably involves that individual reaching beyond the scope at which they've worked to learn new things about other parts of the system, or "going deeper" into one particular area. (Ron later came to work with me at another company, where he is the resident expert on topics related to the Java Virtual Machine: garbage collection, threading and synchronization, code loading, you name it. He's still that "go-to" guy, all these years later, just on a different technology these days.)

Documenting the expectations#

A reasonable question for any employee (including yourself!) to ask is, "Where are the expectations to which I'm being held listed? Can I look at them?" Much of the time, these will be listed in the form of a "job description" (JD), the same document used as part of the recruiting/hiring process. In fact, it's not uncommon for an employee to never see a formal description of their job expectations once they've been hired.

Part of the "clear" in "clear expectations" should be understood to mean "clearly available." On any given day, an employee should be able to reference the set of expectations to which they are being held accountable and, ideally, be able to see the expectations for positions above or "near" their current role, for purposes of charting out their own career path.

Job descriptions are not always published. Be aware that this may be more of a sensitive subject than you imagine at first. At least one company I know of has actually held that their promotional criteria are a "company secret" and therefore not accessible to anyone below the Director level. Another place (where I worked!) held all job descriptions inside the HR system and denied employees access to all JDs (except their own) unless you were Director level or above. Sometimes these restrictions are oversight and sometimes they have historical reason, but within the boundaries of your company's policies, make it clear to your employees what you and your company expect of them. (And, might I suggest, work with your HR partners to open up that information for employees so that they can have an easier time growing and getting better!)

Some companies have taken to publishing some of their career matrix or ladders online—it can be very helpful and educational to examine these and see how they measure up against your own company's expectations. Square published theirs in a blog post, as have other companies. Most of the time, you will not be able to use them "out of the box," but these can serve as useful starter material.

Keep in mind, too, that depending on the size of your company, you will likely be operating under a set of job expectations that were developed (and are likely owned) by the HR team. Talk to your HR partners about any questions you have or revisions you want to suggest, and ask for interpretations of what's not clear. You need to be a reasonably well-informed source of answers when your employees ask those same questions.